G Suite Security Tip #1 — That One Weird Multifactor Trick to Stop Phishing & Account Takeovers on Your Domain
Over the years there have been numerous high-profile attacks that have compromised accounts hosted on Google Mail or the G Suite. There are some highly effective measures that can be taken to help prevent these scenarios. And the most important tip is probably…
Enforce Multifactor Authentication to Protect from Phishing
Phishing is both the most common and also one of the most effective techniques in attacker playbooks. So when it comes to the G Suite, phishing is without question the #1 risk for organisations, since so much business data can be accessed from anywhere on the internet with only one set of credentials.
Every organisation on G Suite that is in business should enforce multifactor authentication measures to protect their employees and their data .
With multifactor authentication, users need more than just a password to sign into their account. So if a user gets phished and sends their password to an attacker, that one compromised credential is not sufficient to gain entry into the user’s account.
Multifactor will also help defend users that set weak passwords, or users that have their passwords leak due to improper password use on a third party site.
To start off with, if you have an existing Single Sign On solution which supports SAML it could already be compatible with the G Suite and should already have strong multifactor authentication options. Products such as Duo Protect and Okta Cloud Connect provide instructions on how to work with the G Suite integration. The tips below may also be helpful when deciding which multifactor mechanisms to enforce with a SSO solution.
For enterprises that decide not to integrate G Suite with their SSO or do not have an identity provider, the G Suite offers a number of builtin multifactor options that can be configured and enforced.
FIDO U2F
This is the strongest form of second factor authentication available with the G Suite. The U2F protocol (Universal 2nd Factor) is an open authentication standard for authenticating users with a USB or NFC hardware device. To sign-in to a service, users both enter their credentials and interact with their hardware device to physically confirm their intent to sign-in to a service.
Under the hood, U2F is significantly more secure than some of the other two-factor mechanisms such as TOTP or SMS.
For starters, as with other security keys, a separate physical token is required making it highly difficult for an attacker to steal the secret credentials for this form of second factor authentication and reuse them on a secondary device. These physical tokens also require manual human interaction to perform an authentication attempt.
Next, U2F uses public key cryptography so that there is no shared secret between the authentication server and the U2F device. This limits attacker capabilities in a number of ways. For example, a rogue administrator would not be able to steal a shared secret for generating two factor codes and later impersonate users silently.
More critically, browser vendors are rolling out built-in support for U2F authentication. When a user authenticates to a website with their token, the device answers a cryptographic challenge-response. As part of the process, the token also signs the origin of the request and the TLS Channel ID, which adds seriously strong resilience against a phishing attack on a technological basis. If a user is not on the correct website when they enter their credentials, the signed parameters wouldn’t match on the authentication server. This is what makes U2F a great choice when it comes to multifactor authentication.
Google Prompt
As an alternative to a security key, users can use their smart phone to authenticate themselves to sign in with push method. When a user wants to sign in, they express their intent on their computer and then confirm the sign-in on their phone using the Google app. On iPhone, a phone with Touch ID is required, and on Android the screen lock must be enforced.
This is a great alternative for organisations that already distribute smart phones to their members. Beware, however, that it would not be recommended to have employees use their personal devices to authenticate to corporate G Suite resources.
Because the credentials are sent out of band, there is nothing for phishers to lift and replay for second factor authentication. Without that second factor, the user’s password is insufficient for gaining access when multifactor authentication is enforced.
TOTP Codes
The Time-based One-Time Password Algorithm (RFC 6328) uses codes that users enter along with their passwords to authenticate. These codes are based on the current time and a shared secret key that was distributed to users upon registration. Typically the code is transmitted with a QR code to a smart phone that will be later used for generating authentication codes.
There are a number of limitations with TOTP. One is that they are clumsy, users have to read and enter codes. These are typically 6-digits codes with a search space of roughly a million entries which is well within the realm of possibility for brute force if a server does not have appropriately strong rate limiting.
Another more critical issue is that TOTP is not particularly effective against phishing attacks since attackers can automatically replay the TOTP authentication code to the real server. If a user is entering their password during a phishing attack they are also very likely to pass along their authentication code. Still, it’s significantly better than no second factor and helps tremendously with weak or compromised passwords.
Another common anti-practice is that many people, especially IT staff and system administrators, move their OTP generator to the same computer they are authenticating with for convenience rather than keeping their generator on a physically separate device. If an endpoint is compromised, attackers can swipe the generator keys. This is unfortunate because in some cases two-factor could otherwise slow down lateral attacker movement masquerading as a legitimate user.
Voice & SMS Text
G Suite also supports Voice & SMS for authentication. This is often used as a backup mechanism during onboarding. This has the nice property that it is out of band, but it has some downsides. Namely, cost and reduced security. On the cost front this option would require organisations provide a phone number and a phone to their members or rely on people’s personal telephone numbers (not recommended). Realistically many businesses use Voice & SMS as a fallback to prevent password lockout, but they should consider carefully if this is wise.
Many carriers are vulnerable to social engineering and similar attacks, and we’ve seen documented cases of phone numbers being hijacked to bypass SMS-based multifactor authentication.
Another downside depends on how serious an organisation’s threat model is. If an organisation has sufficient risk (or tinfoil hats), that it seriously imagines attackers with a six figure offensive budget, or has concerns about operating across many borders, it’s not unreasonable to plan that SMS could be compromised by adversaries on a technological basis as well.
(Aside: For businesses looking for end-to-end secure communications, we would not recommend Apps which employ SMS codes as their primary authentication mechanism without an additional second factor such as a password)
What are the true costs of multifactor?
Multifactor authentication adds safety brakes to light-speed access to G Suite business data, from anywhere in the world. This will slow down employees when they lose their second factor credentials, and make onboarding require some extra steps. Similarly administrators need to plan for how to securely verify remote employees when managing credentials. It does need some education and training, and generally raise support costs for an organisation.
On the flip side, the multifactor safety brakes will greatly mitigate the risks of phishing and poor password security, saving an organisation large amounts of time, money and energy that would be spent on a real incident. The number of high profile intrusions related to phishing and poor password safety over the past few years should ring alarm bells, and multifactor authentication is one of the most effective way to protect an organisation.
In terms of overall usability, G Suite has optimised authentication by caching proof of authentication in cookies so that the second factor isn’t required as often as you might expect. The frequency is typically about once a month per device. Something else to keep in mind is that once second factor becomes a habit for users, they really don’t notice the extra effort, and people generally respond positively, according to Google’s U2F case study. The hard part is making the switch, but again, that switch is much easier than doing a cleanup after a major incident.
Which Authentication Mechanisms To Pick?
One thing to consider is that some mechanisms lend better to mobile authentication than others. U2F is not solid yet on mobile devices outside of the Android ecosystem, so Google Push or similar services may be a better choice for now for organisations that are reliant on mobile.
By order of strength, we would list the G Suite multifactors options as follows: U2F, Google Push/Duo, TOTP, and SMS. By cost, distributing smart phones to employees is the most expensive. The cost of U2F tokens is negligible compared to that but there is also a cost for physical tokens.
We would also strongly recommend against employees of a business from using their personal devices to authenticate to the business G Suite. Based on your needs this may not be possible, but there may be legal and ethical implications when requiring personal devices to hold credentials to business information. Importantly, it’s not possible to expect business MDM of personal devices. And from past IR experience, one of the most stressful and embarrassing situations to be in for IT, IR, and team members is when an intrusion has overlap with someone’s personal life. It’s really best not to ask employees to entangle their personal data with business data. Yet another aspect is that your business inventory can be used to verify which devices are accessing your systems, and if employees use personal devices it becomes much more difficult to detect unauthorised access from anomalous devices.
It’s also possible to mix and blend second factor authentication mechanisms to some degree and have some options as backup mechanisms for G Suite. Some things are not compatible for now, for example G Suite can employ either Google Push or a U2F key for a single user but not both simultaneously.
To make a decision, an IT team should work through the onboarding and recovery process of the various multifactor mechanisms they are considering to discover their best fit. Factors such as remote offices, employee travel frequency, and whether or not smart phones are provided to members are some of the things to think about.
One other thing to figure out is integration requirements beyond G Suite. Generally, you want the same second-factor mechanisms used with G Suite available across most of the other web services your organisation is authenticating to. If your organisation uses another authentication mechanism for single sign-on, the second-factor mechanisms for G Suite should also integrate well with that and other authentication mechanisms. There are third parties to consider in this space as well such as as Duo or Okta.
G Suite provides some flexibility as well with support for acting as an identity provider for SAML or perhaps your organisation could decide to go big on Google for IT and use their Cloud Identity Aware Proxy (UberProxy) for all your web service integrations. An organisation that is very concerned with full control over its IT might want to threat model the impact of Google downtime, or a Google compromise on their non G Suite data and infrastructure before making that choice.
Additional Security Measures
On the people side, training and a mature security culture are also very good defenses. Phishing does not end with password safety. It could be about asking for sensitive information over email or tricking users into running malicious code. In the G Suite world, phishing could be about authorizing malicious OAuth applications that grant scopes to a user’s documents and emails. For these reasons security awareness and phishing simulation trainings are still a very good idea.
If you’re a G Suite Enterprise customer ask your account representative about third-party apps DLP, this feature will allow you to lock down OAuth on your domain with whitelisting to prevent phishing
An additional safety feature to be aware of is that Google provides anomaly detection by default to block any suspicious logins and alert users. If the authentication systems flag an account as potentially compromised, it will suspend the account until an administrator takes action. This serves to help slow down attackers performing phishing attacks.
Resources
Update: May 4th, 2017. Due to the Google Phishing Worm going around we updated the OAuth sections to describe the Third Party Apps DLP feature in Beta for Google Enterprise customers
